Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial standalone sx126x driver [WIP] #15795

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

keever50
Copy link

@keever50 keever50 commented Feb 9, 2025

Summary

This is a driver I am working on for the SX126x (SX1261 and SX1262) LoRa chips. NuttX only had the SX127x drivers before, which are the older variant LoRa chips which are becoming less common.

All functions and definitions are coming directly from the DS SX1261-2 V2.1 datasheet.

There are already existing SX126x drivers out there. For example, Semtech provides one themselves. There is also one written in Rust. This one is not vendor-driven and more free. Ofcourse also specifically made for NuttX in C.

Impact

This chip's output (RF) can communicate with the older variant chips, because it uses the same LoRa modulation. However, there are a few extra features to modulate LoRa beyond what the older variant can do.
For internal compatibility, it is about the same story. It got common features but also got new features.
The drivers in the other hand are not very identical. The chip is being handled differently than the older variant.

This driver allows a lot more IoT boards to be added to NuttX, because most of them using LoRa will use the new SX126x variants.

Testing

Deep testing has yet to be done. Other than there being one test function for development that fires when you open up the device.
This is mainly developed on Linux and a rak11310 board. This rak11310 board is also not yet supported by NuttX because it's main feature is the new LoRa chip. I may add this board to NuttX once it is ready. This might be useful for testing as well.

WIP!

Do not pull this before it is usable. Currently it is not integrated as a driver and purely a preview. I am asking for help or advice on how to take the next steps.
Currently it is missing:

  • Some less significant hardware features
  • NuttX driver integration
  • Filesystem / ioctl
    And probably a few other things.

let me know what you think and if you want to help!

@github-actions github-actions bot added Area: Drivers Drivers issues Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces. labels Feb 9, 2025
@nuttxpr
Copy link

nuttxpr commented Feb 9, 2025

[Experimental Bot, please feedback here]

Fill In The Commit Message: This PR contains a Commit with an Empty Commit Message. Please fill in the Commit Message with the PR Summary.

This PR, as it stands, does not meet the NuttX requirements. While the idea is promising and addresses a real need, it's currently too incomplete to be considered a proper pull request. Here's why:

  • Summary: Lacks specific details on what has been implemented. Mentioning "all functions and definitions from the datasheet" is not helpful without specifying which ones are done. The summary should clearly state the current state of the driver (e.g., "Initial implementation of the SX126x driver, including basic initialization and register access").

  • Impact: While mentioning expanded board support is good, the impact section needs to be more concrete. Currently, it's too general. Since the driver isn't functional, many impacts are unknown. Focus on the current impact of this incomplete PR. For example:

    • Impact on user: None yet, as the driver is not usable.
    • Impact on build: Minimal, adds source files. (Be specific about which files)
    • Impact on hardware: None yet, as the driver is not integrated.
    • Impact on documentation: None yet. Documentation will be added upon completion.
    • Security: Unknown. Will be assessed upon completion.
    • Compatibility: Unknown. Will be addressed upon completion.
  • Testing: Insufficient. "Deep testing has yet to be done" is unacceptable for a PR. Even for work-in-progress, some basic functionality should be demonstrable and testable. The provided "testing logs" are nonexistent. At the very least, demonstrate register read/write functionality. Even if the driver can't transmit/receive yet, some testing is required.

  • WIP Status: Marking a PR as WIP is generally discouraged in NuttX (and most open-source projects). It's better to develop on a branch and only submit a PR when it's closer to being ready for review.

Recommendations:

  1. Focus on a minimal viable implementation: Instead of trying to implement everything at once, focus on a core set of functionalities (e.g., initialization, register access, basic transmit/receive). Get that working and tested first.

  2. Provide concrete examples: Show code snippets of the implemented functions, and provide specific register settings used in your test.

  3. Actual testing logs: Include real logs demonstrating the functionality you have implemented.

  4. Break down the work: Create separate issues for individual features (e.g., "Implement LoRa modulation," "Add SPI communication," "Integrate with NuttX driver framework"). This allows for more focused development and review.

  5. Seek feedback earlier: Instead of submitting an incomplete PR, consider opening a discussion on the NuttX mailing list or forums to discuss your approach and get feedback before writing a lot of code.

By following these recommendations, you can create a PR that meets the NuttX requirements and is more likely to be accepted.

FAR struct sx126x_dev_s g_sx126x_devices[SX126X_MAX_DEVICES];
static const struct file_operations sx126x_ops =
{
sx126x_open, sx126x_close, sx126x_read, sx126x_write, 0, 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put an operation by line, it is easier to stop mistake or missing ops

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agreed. This is very much a placeholder thing. I started off with a template for this. Will do.

@keever50
Copy link
Author

keever50 commented Feb 9, 2025

I am not entirely sure why all the indents are triple space now. Maybe something happened after copying the file over and it somehow magically auto formatted it to tripple space from doubles. Maybe someone has an idea

@keever50
Copy link
Author

hm, i dont think that squashed, or did it

@keever50
Copy link
Author

I am not sure if i should keep squashing it with force pushing on every change. Tell me if i am doing something wrong. Learning new things

return -EINVAL;
}

printf("Reading\n");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest replacing printf() with syslog info or debug info() macro

Copy link
Author

@keever50 keever50 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah good idea, also just placeholder for now. I am planning on replacing all of these to wlerr, wlinfo, etc. We have one of these already, so might as well. I just partially integrated everything into Nuttx, such as public includes, Kconfig and make files. I am testing everything on a board as described before. Is it a good idea to just add this one into this PR later? That makes things a bit easier.

return -EINVAL;
}

printf("Trying to write\n");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

@acassis
Copy link
Contributor

acassis commented Feb 16, 2025

ping @keever50

@keever50
Copy link
Author

pong @acassis

Update:
Still working on it on a different branch to not spam this PR.
Things are fully integrated, added a board for testing and made an app for testing.
Nearly all SX126x features are implemented, except for some ioctl commands.

Just did a ping pong test with two radios and it works perfectly.

Will PR when ready. Most likely this week.

@keever50
Copy link
Author

I can drop the updates here for review if you like but it is not fully cleaned up yet.

@keever50
Copy link
Author

Let me know if these integrations and ioctl look OK. I would appreciate that. If anything has to be changed lmk

@acassis
Copy link
Contributor

acassis commented Feb 16, 2025

Let me know if these integrations and ioctl look OK. I would appreciate that. If anything has to be changed lmk

@keever50 I suggest just separating the board support from the driver. You can still keep everything is in PR, just separate logically the driver from the board

@keever50
Copy link
Author

@acassis Is it okay if i create a completely new fresh PR somewhere this week with the clean up and board removed? This makes things a bit easier to manage. Later afterwards i can do a PR for the board and a PR for the example app in the different repo. Ill make sure to link back to this PR. I am still quite new to open source projects.

@raiden00pl
Copy link
Member

hi, can we make this driver interface compatible with sx127x ? It would be ideally if this driver can work with sx127x_demo example. this will probably require breaking changes in the sx127x API, but in this case it will be justified.

@keever50
Copy link
Author

@raiden00pl yes! i was thinking about trying to do this... are we sure we want to break the API? Maybe we can add wrapper macros that point to SX12XX ioctls. That way old apps dont need to be ported.
Both SX126x and SX127x can use the same IOCTL in that case.

@keever50
Copy link
Author

There are quite some things in common between these devices. For pretty much all LoRa devices(SF, BW). Maybe it would be nice to have ioctls for common lora devices. Let me know what you think.

@raiden00pl
Copy link
Member

I think that a portable API is more important than breaking the code for a few users. Breaking changes will be easy to detect and fix (compiler errors), most likely it will be some names change in the user code. The sx127x API was never mature (I say this as the author of this driver), so I think this is a perfect example where a breaking change is justified. But that's just my opinion :)

@raiden00pl
Copy link
Member

#15828 here is another PR with LORA chip support. Shared ioctl will be beneficial for this driver as well

@keever50
Copy link
Author

@raiden00pl good points.

What do we imagine the ioctl commands would look like?

Currently in that PR i see that WLIOC is used to implement specific LoRa features. Personally i think it would be logical to say WLIOC_LORA_xxx instead putting it all on WLIOC that might be shared with other modulations, such as GFSK, OOK etc.
This might make it easier to spot incompatible parameters.

This allows WLIOC_GFSK, WLIOC_OOK etc in the future as well.
I know the sx126x and 127x can benefit from these modulation specifics. They both can do GFSK. 127x can even do OOK.
That solves that problem of awkwardly hiding them away between all the other names.

@keever50
Copy link
Author

keever50 commented Feb 18, 2025

I will do more testing on this driver and put a test report here this week. Also go over the code for a cleanup.

@keever50 keever50 force-pushed the sx126x_lora_driver branch 2 times, most recently from c1e8ddb to 66d63cc Compare February 22, 2025 12:25
@keever50
Copy link
Author

image
And obviously, it also works from across the room. Message "Hello" is sent using the app from PC over LoRa.

@keever50
Copy link
Author

Actually, @acassis if approved. Can this be pushed? This would significantly help testing it as boards and apps dont have to be removed from the PR every time. The rest of the less significant features, common API and RSSI/SNR can be implemented soon after.

@keever50 keever50 marked this pull request as ready for review February 22, 2025 13:26
@keever50 keever50 force-pushed the sx126x_lora_driver branch 2 times, most recently from d70d248 to ab612b6 Compare February 23, 2025 19:40
@keever50
Copy link
Author

Added a comment to both headers about this driver being currently experimental and breaking changes might happen in the near future.

@keever50
Copy link
Author

Signed and changed message. Also includes [experimental] as tag.
It is review ready.

@xiaoxiang781216
Copy link
Contributor

xiaoxiang781216 commented Feb 24, 2025

#15828 here is another PR with LORA chip support. Shared ioctl will be beneficial for this driver as well

I suggest to follow the suggestion from @raiden00pl before merging this patch. The unified usersapce interface is very important for any os.

@keever50
Copy link
Author

@xiaoxiang781216 Yes thats the idea, however it could help to have this one pushed as experimental driver. So i can push a board and app which can be used for testing.
Currently my board and app are private. The board has to be removed after each merge and people cannot test it the way i can test it.

Later when the common API is decided on, this driver can be updated and the [experimental] tag can be removed. (using a new PR).

However, I'm fine with waiting as well if that works better for NuttX. It might be less efficient.

@keever50
Copy link
Author

The common API is discussed here #15856

@acassis
Copy link
Contributor

acassis commented Feb 24, 2025

@keever50 please create also the Documentation/ and include the screenshots about the SDR and NSH to let people get more information before using it.

@keever50
Copy link
Author

@acassis I can do that.
Is it a good idea if i create a directory called /wireless/lpwan under /documentation/components/drivers/character/ ?
I am not very familiar with this documentation system. Is it possible to manually do this using the github website?

@acassis
Copy link
Contributor

acassis commented Feb 24, 2025

@acassis I can do that. Is it a good idea if i create a directory called /wireless/lpwan under /documentation/components/drivers/character/ ? I am not very familiar with this documentation system. Is it possible to manually do this using the github website?

Yes, sounds good!

@keever50
Copy link
Author

Documentation added

@github-actions github-actions bot added the Area: Documentation Improvements or additions to documentation label Feb 24, 2025
Copy link
Contributor

@jerpelea jerpelea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add the documentation in a separate commit

@keever50
Copy link
Author

oh ok i misunderstood the request then. Ill remove it.

[Experimental]
This adds a driver for the SX126x (SX1261 and SX1262) LoRa chips.
All functions and definitions are coming directly from the DS SX1261-2 V2.1 datasheet.

Signed-off-by: Kevin Witteveen (MartiniMarter) <[email protected]>
@github-actions github-actions bot removed the Area: Documentation Improvements or additions to documentation label Feb 25, 2025
@keever50
Copy link
Author

adding it as seperate commit

@github-actions github-actions bot added the Area: Documentation Improvements or additions to documentation label Feb 25, 2025
* ``-x`` perform transmit and receive. Transmits following bytes and attempts to receives immidiately. To be used with ``-e`` echo
* ``-e`` perform echo. Listen and repeat.

.. image:: https://private-user-images.githubusercontent.com/9679272/415904583-3a979608-6386-4b51-8d0e-acf09d918299.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDA0MjAwODIsIm5iZiI6MTc0MDQxOTc4MiwicGF0aCI6Ii85Njc5MjcyLzQxNTkwNDU4My0zYTk3OTYwOC02Mzg2LTRiNTEtOGQwZS1hY2YwOWQ5MTgyOTkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIyNCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMjRUMTc1NjIyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MDk5MDk1NzY2MjYzMGJlNWVkMWFiYTAwNWU0OGM3N2JkMDBmN2Q5Yzk0MDY3MjNkY2IxZWM5MzM2Nzc4YWM5NSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.6JOsN_-uyyxnlxHg33Bt_WT5DFSO_i-Uh4coi-8xpEc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please include the image in the repository, external links can disappear or be moved to other URL

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, ofcourse! Also fixed the index error.

Signed-off-by: Kevin Witteveen (MartiniMarter) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Documentation Improvements or additions to documentation Area: Drivers Drivers issues Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants